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METHOD AND APPARATUS FOR FACILITATING A TRANSACTION 
BETWEEN A BUYER AND ONE SELLER 



CROSS-REFERENCE TO CO-PENDING APPLICATIONS 
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Patent Application No. 09/190,744 entitled METHOD AND APPARATUS FOR A 
CRYPTOGRAPHICALLY ASSISTED COMMERCIAL NETWORK SYSTEM 
DESIGNED TO FACILITATE BUYER-DRIVEN CONDITIONAL PURCHASE OFFERS" 
to Bruce Schneier, James A. Jorasch and Jay S. Walker filed on November 12, 1998 
10 (Attorney Docket No. WD2-96-008XXX), which is a continuation-in-part of co-pending U.S. 

patent application Serial No. 09/058,840 entitled "METHOD AND APPARATUS FOR A 
O CRYPTOGRAPHICALLY ASSISTED COMMERCIAL NETWORK SYSTEM 
j DESIGNED TO FACILITATE BUYER-DRIVEN CONDITIONAL PURCHASE OFFERS" 
^ to Bruce Schneier, James A. Jorasch and Jay S. Walker filed on April 13, 1998 (Attorney 
15 Docket No. WD2-96-008XX), which is a continuation-in-part of co-pending U.S. patent 
Tj application Serial No. 08/889,3 1 9 entitled "CONDITIONAL PURCHASE OFFER 
ij MANAGEMENT SYSTEM" to Bruce Schneier, James A. Jorasch, Jay S. Walker and T. 
33 Scott Case filed on July 8, 1997 (Attorney Docket No. WD2-96-008X) which is a 

continuation-in-part of U.S. Patent No. 5,794,207 entitled "METHOD AND APPARATUS 
2 0 FOR A CRYPTOGRAPHICALLY ASSISTED COMMERCIAL NETWORK SYSTEM 

DESIGNED TO FACILITATE BUYER-DRIVEN CONDITIONAL PURCHASE OFFERS" 
issued on August 11, 1998 to Bruce Schneier, James A. Jorasch and Jay S. Walker; and a 
continuation-in-part of co-pending U.S. patent application Serial No. 08/997,170 entitled 
"CONDITIONAL PURCHASE OFFER BUYER AGENCY SYSTEM" to Andrew S. Van 
25 Luchene, Daniel E. Tedesco, James A. Jorasch, Jay S. Walker and Thomas M. Sparico filed 
on December 22, 1997 (Attorney Docket No. WD2-97-314), which is a continuation-in-part 
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of co-pending U.S. patent application Serial No. 08/923,683 entitled "CONDITIONAL 
PURCHASE OFFER (CPO) MANAGEMENT SYSTEM FOR PACKAGES" to Andrew S. 
Van Luchene, Daniel E. Tedesco, James A. Jorasch, Jay S. Walker and T. Scott Case filed on 
September 4, 1997 (Attorney Docket No. WD2-97-065) and a continuation-in-part of co- 
5 pending U.S. patent application Serial No. 08/943,266 entitled "SYSTEM AND METHOD 
FOR AGGREGATING MULTIPLE BUYERS UTILIZING CONDITIONAL PURCHASE 
OFFERS (CPOs) to Daniel E. Tedesco, James A. Jorasch and Jay S. Walker filed on October 
3, 1997 (Attorney Docket No. WD2-96-084), each incorporated herein by reference. 

1 0 CROSS-REFERENCE TO CO-PENDING RELATED APPLICATIONS 

p This application is related to the following co-pending U.S. patent applications: Serial 

fU No. 08/923,530 entitled "CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEM 

-=53. 

'^Z FOR EVENT TICKETS" to Andrew S. Van Luchene, Bruce Schneier, James A. Jorasch, Jay 
7" S. Walker , Robert R. Lech and Thomas M. Sparico filed on September 4, 1997 (Attorney 
jjf Docket No. WD2-96-08 1 ); Serial No. 08/923,3 1 7 entitled "CONDITIONAL PURCHASE 
y OFFER MANAGEMENT SYSTEM FOR TELEPHONE CALLS" to Bruce Schneier, Jay S. 
CO Walker and Thomas M. Sparico filed on September 4, 1997 (Attorney Docket No. WD2-97- 
028); Serial No. 08/964,967 entitled "CONDITIONAL PURCHASE OFFER (CPO) 
MANAGEMENT SYSTEM FOR COLLECTIBLES" to Andrew S. Van Luchene and Jay S. 
2 0 Walker filed on November 5, 1 997 (Attorney Docket No. WD2-97-066); Serial No. 

08/923,524 entitled "CONDITIONAL PURCHASE OFFER (CPO) AND .THIRD-PARTY 
INPUT MANAGEMENT SYSTEM" to Bruce Schneier, Jay S. Walker, Sanjay K. Jindal and 
Toby Weir- Jones filed on September 4, 1997 (Attorney Docket No. WD2-97-067); Serial No. 
08/969,875 entitled "CONDITIONAL PURCHASE OFFER (CPO) MANAGEMENT 
2 5 SYSTEM FOR VEHICLE LEASES" to Jay S. Walker and Toby Weir- Jones filed on 
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November 14, 1997 (Attorney Docket No. WD2-97-068); Serial No. 08/923,618 entitled 
"CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEM FOR CRUISES" to 
Bruce Schneier, Jay S. Walker, T. Scott Case and Thomas M. Sparico filed on September 4, 

1997 (Attorney Docket No. WD2-97-069); Serial No. 08/943,483 entitled "SYSTEM AND 
5 METHOD FOR FACILITATING ACCEPTANCE OF CONDITIONAL PURCHASE 

OFFERS (CPOs) to Andrew S. Van Luchene, Daniel E. Tedesco, James A. Jorasch, Jay S. 
Walker and Thomas M. Sparico filed on October 3, 1 997 (Attorney Docket No. WD2-97- 
072); Serial No. 09/xxx,xxx entitled "DYNAMIC QUALITY CONTROL CONDITIONAL 
PURCHASE OFFER (CPO) MANAGEMENT SYSTEM" to Daniel E. Tedesco, James A. 
10 Jorasch, Jay S. Walker and T. Scott Case filed on December 4, 1998 (Attorney Docket No. 
jj WD2-98-064); Serial No. 09/xxx,xxx entitled "METHOD AND SYSTEM FOR UTILIZING 
fCi A PSYCHOGRAPHIC QUESTIONNAIRE IN A BUYER-DRIVEN COMMERCE 
*Z SYSTEM" to Daniel E. Tedesco, James A. Jorasch and Jay S. Walker filed on December 4, 

1998 (Attorney Docket No. WD2-98-066); Serial No. 09/xxx,xxx entitled "CUSTOMER 
IJ PROFIT SHARING CONDITIONAL PURCHASE OFFER (CPO) MANAGEMENT 

y SYSTEM" to Daniel E. Tedesco, Jay S. Walker and T. Scott Case filed on December 4, 1998 
A (Attorney Docket No. WD2-98-074); and Serial No. 09/xxx,xxx entitled "SYSTEM AND 
METHOD FOR MOTIVATING SUBMISSION OF CONDITIONAL PURCHASE 
OFFERS" to Daniel E. Tedesco, Jay S. Walker, T. Scott Case and Tracy Hartmann filed on 
2 0 December 4, 1998 (Attorney Docket No. WD2-98-075), each incorporated herein by 
reference. 

FIELD OF THE INVENTION 

The present invention relates to a method and apparatus for facilitating 
2 5 transactions between buyers and sellers. 
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BACKGROUND OF THE INVENTION 

Sellers of various products typically advertise a predetermined price for a 
product, and customers pay that price for the product. The parent applications of the present 
application describe a method and apparatus that permits sellers to accept "conditional 
purchase offers" from buyers, in which a conditional purchase offer specifies a price the 
buyer is willing to pay for the product. Each conditional purchase offer is further associated 
with a payment identifier that specifies a financial account to "guarantee" the offer. If a seller 
accepts the offer, then that seller can be paid using the payment identifier. Even if the buyer 
later reneges, the payment identifier guarantees that the seller receives appropriate 
compensation, typically either the full offer price or a predetermined penalty payment. 

The inventions disclosed in the parent applications are especially 
advantageous in selling excess, perishable inventory such as seats on airline flights. For 
example, the marginal cost to an airline of selling an additional seat is extremely low. 
Accordingly, it can be profitable to sell a seat for a low, buyer-specified offer price, 
especially if the chance of otherwise selling the seat is small (e.g. soon before the flight 
departs). 

However, for various reasons, sellers may believe, correctly or incorrectly, 
that the drawbacks of such a system as outweighing the advantages. For example, a seller 
may believe that such a system forces undue competition among sellers for customers that 
submit offers. For example, if the seller does not accept a reasonable offer, another seller 
probably will. In fact, the seller may feel compelled to accept unusually low offer prices out 
of fear that another seller may gain the repeat business of the customer. Although some 
sellers may have, in fact, incorrectly assessed the magnitude of such drawbacks, the 
perception alone can prevent the sellers from participating in such a system. 
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Accordingly, it would be advantageous to provide a method and apparatus for 
processing conditional purchase offers in a manner that reduced the concerns of sellers. 



SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a method and apparatus for 
processing conditional purchase offers in a manner that reduced the concerns of sellers. 

In accordance with the present invention, a seller server receives an offer 
which specifies a type of product (e.g. a seat on a flight), at least one condition (e.g. 
destination and date of departure), and an offer price specified by a buyer. The seller server 
also receives an associated payment identifier that specifies a financial account, such as a 
credit card account. The payment identifier essentially "guarantees" the offer in that the 
seller may receive payment from the financial account even if the buyer attempts to renege. 
The seller determines whether to accept the offer, based on various factors such as the offer 
price and the availability of appropriate products to satisfy the conditions of the offer. If the 
offer is accepted, payment is provided to the seller using the payment identifier. The seller 
does not compete with other sellers for the received offers. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A is a schematic illustration of an apparatus for facilitating transactions 
between buyers and sellers. 

FIG. IB is a schematic illustration of another embodiment of an apparatus for 
facilitating transactions between buyers and sellers. 

FIG. 2 is a schematic illustration of a seller server of the apparatus of FIGS. 

lAand IB. 

FIG. 3 is a representation of a buyer database of the seller server of FIG. 2. 
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FIG. 4 is a representation of an inventory database of the seller server of FIG. 

2. 

FIG. 5 is a representation of an offer database of the seller server of FIG. 2. 
FIG. 6 is a representation of a collected demand database of the seller server 

5 of FIG. 2. 

FIG. 7 is a graph representing demand collected for a specific type of product 
having certain conditions. 

FIG. 8A is a flow chart illustrating an embodiment of a method for facilitating 
a transaction between a buyer and one seller. 
10 FIG. 8B is a flow chart illustrating another embodiment of a method for 

facilitating a transaction between a buyer and one seller. 

FIG. 9 is a flow chart illustrating a method for facilitating a transaction 
2 between a buyer and one seller using a counter offer from the seller. 

nj FIG. 1 0 is a flow chart illustrating a method for selecting a product to fulfill an 

fcS offer. 

H FIG. 1 1 is a flow chart illustrating a method for accepting offers. 

!r; FIG. 12 is a flow chart illustrating a method for concealing a minimum 

1 ~fi acceptable price of a product. 

ffi FIG. 1 3 is a flow chart illustrating a method for assessing demand for a 

2 0 product. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Applicants have recognized that sellers may prefer to work separately from 
other sellers in receiving offers from buyers. Furthermore, a single seller may be able to 
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provide its buyers with more flexibility in accepting their offers. Such flexibility would 
benefit the buyers as well as the seller. 

The seller may benefit or believe it can benefit from the absence of other 
parties, such as a central controller operated by a third party. Accordingly, the seller may 

5 prefer to receive offers directly from buyers. In such an embodiment, the seller may be able 
to circumvent certain transaction costs that would be paid to other parties. 

As described in the parent applications of the present application, the seller 
may derive significant benefit from receiving such offers from buyers. For example, the 
seller may use revenue management techniques to determine whether it would be beneficial 

0 to accept a particular offer. The seller may also employ revenue management techniques in 
selecting products to fulfill the offers. In addition, conventional (e.g. retail) sales of products 
at retail prices are unaffected by the acceptance of such offers since accepted offer prices are 
not generally known to the public. Thus, the seller may sell at prices below retail prices, 
thereby deriving additional revenue, without starting a "price war" in which competing sellers 

5 lower their prices. Similarly, sellers may have a "reserve" of demand that may be accessed to 
supplement retail demand. 

As described herein, one seller may receive offers directly from buyers, or the 
one seller may employ a central server that receives offers for a plurality of sellers and 
forwards any given offer to one appropriate seller. 

0 Referring to FIG. 1 A, an apparatus 100 includes a seller server 110 that is in 

communication with buyer terminals 120, 130 and 140. The seller server 1 10 may 
communicate with the buyer terminals 120, 130 and 140 via an appropriate network such as 
the Internet. Each of the seller server 1 10 and the buyer terminals 120, 130 and 140 may 
comprise computers, such as those based on the Intel® Pentium® microprocessor, that are 
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adapted to communicate via the Internet (e.g. via a modem). Any number of buyer terminals 
may be in communication with the seller server 110. 

The seller server 110 may be a "web server" of a seller. The seller server 110 
can generate a web page that may be accessed via the World Wide Web and allow offers to 
be submitted to the seller. A buyer terminal may appropriately access the web page to 
communicate with the seller server 1 1 0 in a manner known to those skilled in the art. 

FIG. IB illustrates another embodiment of an apparatus for facilitating 
transactions between buyers and sellers. An apparatus 150 includes a central server 160 that 
is in communication with buyer terminals 120, 130 and 140. The central server 160 is also in 
communication with seller servers 170 and 180. Each seller server may be similar to the 
seller server 110 of FIG. 1 A. A buyer may communicate with the central server 160 to 
submit an offer to a seller, and the central server 1 60 would in turn transmit the offer to one 
appropriate seller server. Each of the seller servers 170 and 180 may generate a web page 
that may be accessed via the World Wide Web and allow offers to be submitted to the 
corresponding seller. The central server 160 could then display the web page. Alternatively, 
the central server 160 may generate an appropriate web page that allows a seller to be 
selected by a buyer. 

The central server 160 may communicate with the buyer terminals 120, 130 
and 140 and with the seller servers 170 and 180 via an appropriate network such as the 
Internet. Each of the central server 160, the buyer terminals 120, 130 and 140 and the seller 
servers 170 and 180 may comprise computers, such as those based on the Intel® Pentium® 
microprocessor, that are adapted to communicate via the Internet (e.g. via a modem). Any 
number of buyer terminals and seller servers may be in communication with the central 
server 160. 
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Referring to FIG. 2, a seller server 200 is representative of the seller server 



1 10 of FIG. 1 A and the seller servers 170 and 180 of FIG. IB. The seller server 200 
comprises a processor 210, such as the Intel® Pentium® microprocessor. The processor 210 
is in communication with a data storage device 220, such as an appropriate combination of 
5 magnetic, optical and/or semiconductor memory. For example, the data storage device 220 
may comprise one or more of a ROM, RAM and hard disk. The processor 210 and the data 
storage device 220 may each be (i) located entirely within a single computer or other 
computing device; (ii) connected to each other by a remote communication medium, such as 
a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination 
1 0 thereof. In one embodiment, the seller server 200 may comprise one or more computers that 
13 are connected to a remote server computer for maintaining databases. 



mf Z 210. The processor 210 performs instructions of the program 230, and thereby operates in 

accordance with the present invention, and particularly in accordance with the methods 
3.j5 described in detail herein. The program 230 furthermore includes program elements that may 
yj be necessary, such as an operating system and "device drivers" for allowing the processor 210 
Sj to interface with computer peripheral devices. Appropriate device drivers and other 

necessary program elements are known to those skilled in the art, and need not be described 
in detail herein. 

2 0 The storage device 220 also stores (i) a buyer database 235, (ii) an inventory 

database 240, (iii) an offer database 245, and (iv) a collected demand database 250. The 
databases 235, 240, 245 and 250 are described in detail below and depicted with exemplary 
entries in the accompanying figures. As will be understood by those skilled in the art, the 
schematic illustrations and accompanying descriptions of the databases presented herein are 

2 5 exemplary arrangements for stored representations of information. A number of other 



The data storage device 220 stores a program 230 for controlling the processor 
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arrangements may be employed besides those suggested by the tables shown. Similarly, the 
illustrated entries of the databases represent exemplary information, and those skilled in the 
art will understand that the number and content of the entries can be different from those 
illustrated herein. 

5 Referring to FIG. 3, a table 300 represents an embodiment of the buyer 

database 235 (FIG. 2). The table 300 includes entries 302 and 304, each defining a buyer that 
submits one or more offers directly or indirectly to one seller server of a seller. Those skilled 
in the art will understand that that the table 300 may include any number of entries. The table 
300 also defines fields for each of the entries 302 and 304. The fields specify (i) a buyer 
10 identifier 320 that uniquely identifies the buyer, (ii) a name 322 of the buyer, (iii) an 
3 electronic mail ("email") address 324 for communication with the buyer, (iv) an address 326 
p(! of the buyer, (v) a day telephone number 328, (vi) an evening telephone number 330, and 
a payment identifier 332 that specifies a financial account that the buyer may use to 
^ render payment. 

15 Referring to FIG. 4, a table 400 represents an embodiment of the inventory 

izj database 240 (FIG. 2). The table 400 includes entries 402, 404 and 406, each defining a 
03 product that a seller offers for sale. In the embodiment illustrated in FIG. 4, the inventory 
database 240 includes seats on flights, and accordingly the seller is a seller of airline tickets. 
Those skilled in the art will understand that that the table 400 may include any number of 
2 0 entries. The table 400 also defines fields for each of the entries 402, 404 and 406. The fields 
specify (i) a flight number 420 that uniquely identifies the flight, (ii) a date 422 of the flight, 
(iii) an origination airport 424, (iv) a destination airport 426, (v) a time 428 of departure of 
the flight, (vi) a time 430 of arrival of the flight, (vii) a number of coach seats available 432 
on the flight, and (viii) a number of business seats available 434 on the flight. 

10 
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Referring to FIG. 5, a table 500 represents an embodiment of the offer 



database 245 (FIG. 2). The table 500 includes entries 502 and 504, each defining an offer 
that a buyer has submitted to the seller. In the embodiment illustrated in FIG. 5, the offer 
database includes offers for seats on flights, and accordingly the seller is a seller of airline 
5 tickets. Those skilled in the art will understand that that the table 500 may include any 

number of entries. The table 500 also defines fields for each of the entries 502 and 504. The 
fields specify (i) an offer identifier 520 that uniquely identifies the offer, (ii) a buyer identifier 
that uniquely identifies the buyer that submitted the offer, (iii) a payment identifier 524 that 
specifies a financial account that the buyer may use to render payment, (iv) an offer price 526 
1 0 that the buyer specifies, (v) offer conditions 528 that a product must satisfy to be acceptable 
3 to the buyer (e.g. a destination, an expiration of the offer), (vi) whether the offer was accepted 
y 530, and (vii) one or more product purchased 532 if the seller accepts the offer. 



l~ demand database 250 (FIG. 2). The table 600 includes entries 602, 604 and 606, each 
hp defining demand received for a type of product. Demand for a type of product is measured 
yj based on the offers that are received for that type of product. In the embodiment illustrated in 
PJ FIG. 6, the type of product is a seat on a flight. To contrast, a product would be one or more 
seats on a specific flight on a particular date from a particular origination airport and to a 
particular destination airport. 
2 0 Those skilled in the art will understand that that the table 600 may include any 

number of entries. The table 600 also defines fields for each of the entries 602, 604 and 606. 
The fields specify (i) an origination 620, which is typically defined as a city and a state; (ii) a 
destination 622, which is typically defined as a city and a state; (iii) a departure date 624; (iv) 
an offer price 626 that was submitted; (v) the number of units of demand 630 that were 
2 5 received, which is typically the aggregation of the number of tickets requested for each offer; 



Referring to FIG. 6, a table 600 represents an embodiment of the collected 
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and (vi) a status 632 of the demand, in particular whether the offers composing the demand 
were accepted. 

The fields such as origination 620, destination 622 and departure date 624 
define conditions that a product must satisfy. Other conditions besides those illustrated may 
5 be defined for seats on flights, as well as for other types of products. 

Referring to FIG. 7, a graph 700 represents illustrative demand collected for a 
specific type of product having certain conditions. The graph 700 is depicted to illustrate 
various uses of the data the graph represents. As indicated by text 702, the graph 700 
represents demand collected for seats on a flight from New York to Los Angeles on 
10 December 20, 1998. The graph 700 may be generated based on offers received from buyers. 
y3 For example, the graph 700 would be based on received offers that included or were 
fit consistent with the conditions represented by the graph 700. Those skilled in the art will 
\2 understand that similar graphs may be generated for various types of products having various 
[™ conditions. For example, a graph could be generated to represent offers for seats on a flight 
A5 from New York to Los Angeles. Alternatively, a graph could be generated to represent offers 
yj for seats on a flight from New York to Los Angeles anytime between December 15, 1998 and 
S3 December 25, 1998. 

The graph 700 includes a vertical axis 704 to indicate units of demand and a 
horizontal axis 706 to indicate offer prices. Each point on the graph thus indicates a quantity 
20 of offers having a specified offer price. For example, a point 708 indicates that there was 

demand for eighty seats at an offer price of $130. Such demand may have been derived from, 
for example, eighty offers for one seat each (80 x 1 = 80), or forty offers for two seats each 
(40 x 2 = 80). A point 710 indicates that there was demand for ten seats at an offer price of 
$200. Such demand may have been derived from, for example, ten offers for one seat each 
2 5 (10 x 1 = 10), or two offers for five seats each (2x5 = 10). A curve 712 indicates demand 
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for the various points of the graph 700, and may represent extrapolated demand at other 
points. 

Referring to FIG. 8A, a flow chart 800 illustrates an embodiment of a method 
for facilitating a transaction between a buyer and one seller. In particular, in the illustrated 
5 embodiment a buyer device communicates via a central server to provide offers to one of a 
plurality of seller servers, as illustrated by the apparatus 150 of FIG. IB. 

The central server receives an offer from a buyer (step 802). As described 
above, the offer specifies a type of product (e.g. a seat on a flight), at least one condition, and 
an offer price specified by the buyer. The offer may specify the type of product explicitly or 
1 0 implicitly. For example, on a web site where offer data is provided by the buyer, the buyer 
rjS may click a button or hyperlink, or otherwise indicate the type of product. Alternatively, the 
nj buyer may specify the type of product by selecting the seller to which he would like to submit 
the offer. 

r= In an embodiment in which the type of product is a seat on a flight, some 

%5 possible conditions that the offer specifies are an origination, a destination, a date of 
hi departure and/or a time of departure. Conditions may specify singular values (e.g. time of 
y3 departure = 8:00 AM) or ranges of values (e.g. time of departure = after 8:00 AM). 

The central server also receives a payment identifier that specifies a financial 
account (step 804). The payment identifier is associated with the offer such that if the offer is 
2 0 accepted the payment identifier may be used to render payment for the product purchased. In 
one embodiment, the offer includes the payment identifier. In another embodiment, the buyer 
submits the payment identifier after submitting the offer. In still another embodiment, the 
buyer submits the payment identifier prior to submitting the offer. For example, the buyer 
may submit the payment identifier during a registration process, if registration is required by 
2 5 the central server. The payment identifier may be stored in the buyer database 235 (FIG. 2) 
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and available whenever it is necessary for payment to be received from the buyer. In such an 
embodiment, the buyer could submit his payment identifier once and subsequently have that 
payment identifier used to render payment for numerous offers. 

In one embodiment, the financial account is a credit card account, and thus the 
5 payment identifier may be a credit card number that specifies the credit card account. In 
other embodiments, the payment identifier may specify debit card accounts, savings or 
checking accounts, or electronic cash. Those skilled in the art will understand that the 
payment identifier may specify other types of financial accounts and currencies. 

The payment identifier is verified (step 806). For example, it may be verified 
1 0 whether the financial account exists and/or whether the financial account has sufficient funds 

T% to pay the offer price. In addition, funds in the financial account may be "frozen" to assure 

rU 

Hi that they are available. 

The offer price may define one or more forms of currency. For example, the 
^ offer price may be a dollar amount (e.g. $200). The offer price may alternatively define a 
jl|5 first amount of a first form of currency, and a second amount of a second form of currency, 
hi For example, one form of currency can be frequent flyer miles that the buyer desires to use, 
03 and thus one exemplary offer price could be "$100 and 10,000 frequent flyer miles". 

In such an embodiment, the payment identifier may specify one or more 
financial accounts for paying the various forms of currency. For example, a single payment 
2 0 identifier such as a credit card number may specify both (i) a credit line which may be used to 
charge various dollar amounts, and (ii) a number of frequent flyer miles associated with the 
credit card account. Alternatively, two or more payment identifiers (e.g. a credit card number 
and a frequent flyer identifier) may be used to specify financial accounts, each of which could 
be debited in accordance with the offer price. 

14 
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The offer is then made available to one seller (step 808). For example, the 
offer may be transmitted via email to a seller server, or the seller server may access a 
database where the central server stores the offer. The seller may be selected explicitly by 
the buyer. For example, the central server may provide a list of available sellers, and the 
5 buyer may in turn select one seller from the list. Alternatively, the seller may be selected 
based on the type of product specified by the offer. For example, if the offer specifies a seat 
on a flight and only one seller could fulfill such an offer (e.g. the only airline to provide such 
a flight), then that seller would be selected. 

In response to the offer, the seller may accept the offer, and the central server 
1 0 receives the acceptance from the seller server (step 810). Payment is then provided to the 
O seller using the payment identifier (step 812). In one embodiment, the central server uses the 
LH payment identifier to debit the offer price from the financial account, and payment is 
ill provided to a seller account. In another embodiment, the payment identifier may be provided 

to the seller, allowing the seller to directly debit the financial account. Those skilled in the 
H 5 art will realize other methods of rendering payment to the seller in accordance with the 
ilJ present invention. 

"if The payment rendered to the seller is typically the offer price specified by the 

offer. In addition, transaction fee may be rendered to the central server or other party. For 
example, a "flat fee" (e.g. $5 per offer) or a commission (e.g. 1% of the offer price) may be 

2 0 charged to the buyer in addition to the offer price. 

The payment identifier essentially "guarantees" payment to the seller, and thus 
the seller is more willing to expend resources to review and accept such offers. Even if the 
buyer reneges or attempts to renege (e.g. if the buyer indicates withdrawal of the offer after it 
was accepted), the full payment (e.g. the offer price) may still be rendered in accordance with 

2 5 a pre-existing contract between buyer and seller. Alternatively, if the buyer reneges or 
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attempts to renege, a penalty payment amount may be charged to the financial account. Such 
a penalty amount may be, for example, a flat fee (e.g. $25) or a predetermined percentage of 
the offer price (e.g. 10% of the offer price). Accordingly, in one embodiment it may be 
desirable to request that the buyer provide authorization to use the payment identifier to 
5 provide payment upon acceptance of the offer. Acceptance could be delayed until such 
authorization is received from the buyer. 



method for facilitating a transaction between a buyer and one seller. In particular, in the 
illustrated embodiment a buyer device communicates directly with a seller server, as 
10 illustrated in FIG. 1A. 



lif above, the offer specifies a type of product (e.g. a seat on a flight), at least one condition, and 
an offer price specified by the buyer. The central server also receives an associated payment 
s identifier that specifies a financial account (step 854), and the payment identifier is verified 
fffi 5 (step 856). The seller server then determines whether to accept the offer (step 858). Various 
W methods may be used to determine whether to accept the offer, as described below. If the 
w offer is not accepted, then the seller server sends an appropriate rejection message to the 
buyer (step 860). Otherwise, payment is rendered to the seller by using the payment 
identifier (step 862) and an appropriate acceptance message is sent to the buyer (step 864). 
2 0 Referring to FIG. 9, a flow chart 900 illustrates a method for facilitating a 

transaction between a buyer and one seller using a counter offer from the seller. As described 
above, an offer from a buyer is received (step 902) and the seller server determines whether 
the offer should be accepted (step 904). If so, then as also described above payment is 
rendered (step 906) and an appropriate acceptance message is transmitted to the buyer (step 



Referring to FIG. 8B, a flow chart 850 illustrates another embodiment of a 



The seller server receives an offer from a buyer (step 852). As described 



25 



908). 
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If the offer is not accepted by the seller, then the seller server may create a 



counter offer that specifies the type of product and a counter offer price (step 910). The 
counter offer price may be based on the offer price. For example, the counter offer price may 
be a predetermined amount less than the offer price to provide the customer with an incentive 
5 to accept. The counter offer may indicate a specific product (e.g. seat 1 12 on flight 1 135 on 
December 20, 1998). Alternatively, the counter offer may specify conditions (e.g. a flight on 
December 20, 1998 from New York to Los Angeles) without indicating a specific product. 



from the buyer is received (step 914). If the response indicates that the buyer accepted the 
10 counter offer (step 916), then payment is rendered using the payment identifier (step 918). 
J Referring to FIG. 10, a flow chart 1000 illustrates a method for selecting a 



fu product to fulfill an offer. The seller server determines all products that satisfy the conditions 

\I of the offer (step 1002). For example, if the offer is for a seat on a flight, and the offer 

I specifies an origination, a destination and a date of departure, the seller server would 

ri5 determine all available seats on flights that depart on the specified date of departure from the 

yj origination to the destination. Additionally, only certain products may be eligible to be used 

CO to fulfill an offer. For example, only certain products may be "allocated" for fulfilling offers. 
Accordingly, the remaining products may be reserved for conventional (retail) sales. 



2 0 these products (step 1004). The minimum price, which is typically lower than the retail price 
of the product, may be based on any of a number of factors. In one embodiment, the seller 
server may determine the minimum price of a product based on the availability of the 
product. For example, if many units of a particular product are unsold (e.g. many seats on a 
particular flight), then the minimum price may be lower than if fewer seats were unsold. In 

2 5 another embodiment, the seller server may determine the minimum price of a product based 



The counter offer is transmitted to the buyer (step 912), and then a response 



The seller server then determines a minimum acceptable price for each of 
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on a comparison of predicted sales of the product and actual sales of the product. For 
example, if the actual sales of the product are less than predicted sales of the product (e.g. ten 
seats on a flight are sold at a certain time when it was anticipated that twenty seats would be 
sold), then the minimum price may be lower than if fewer seats were unsold. In still another 
5 embodiment, the seller server may determine the minimum price of a product based on the 
expected profit from the product. A combination of factors may be used in determining the 
minimum price of a product, and those skilled in the art will realize various other factors for 
determining the minimum acceptable price of a product. 

The seller server then selects a subset of products in which each product in the 
1 0 subset has a minimum price less than or equal to the offer price (step 1006). Such a subset 
~n thus defines the products that are acceptable to fulfill the offer. If the subset includes more 
i_M than one product, then a product is selected from the subset and the selected product is used 
^ to fulfill the offer (step 1008). The step 1008 of selecting a product from the subset may be 
based on any of a number of factors. For example, the product may be selected based on (i) 
if! 5 expected profit from the product, (ii) the availability of the product, (iii) a comparison of 
M predicted sales of the product and actual sales of the product, and (iv) whether actual sales of 
® the product are less than predicted sales of the product. To illustrate, the seller server may 
determine, for each product, an amount by which actual sales of the product are less than 
predicted sales of the product. Then, the seller server could select the product that has the 
2 0 maximal amount by which actual sales of the product are less than predicted sales of the 
product. 

It can be advantageous to perform "load balancing" in determining which 
product is selected to fulfill an offer. For example, if seats on either of two similar flights 
would satisfy the conditions of an offer, it can be advantageous to use a seat on the emptier 
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flight to fulfill the offer. Otherwise, one flight would have a much greater number of unsold 
seats. 

Accordingly, in another embodiment the step 1008 of selecting a product from 
the subset may comprise determining whether sales of a first set of products (e.g. seats on the 
5 first flight) are less than sales of a second set of products (e.g. seats on the second flight). If 
sales of the first set are less than sales of the second set, then a product from the first set is 
A£f selected to fulfill the offer. 

It can also be advantageous to allow the buyer to choose which product he 
would like to fulfill his offer. Accordingly, in another embodiment the step 1008 of selecting 
10 a product from the subset may comprise transmitting an indication of the subset of products 
y3 to the buyer, and then receiving from the buyer a selection of one of the plurality of products. 

f% 3 

FU Referring to FIG. 1 1, a flow chart 1 100 illustrates a method for accepting 

offers. In particular, in the illustrated method acceptance of an offer is delayed to allow 
^ competitive offers to be received. Thus, the seller may gain by not prematurely accepting an 
fifS offer when a better offer may be subsequently received. 

yj The seller server receives offers appropriate to a predetermined product until a 

III predetermined time (step 1002), and does not accept offers until that time. For example, the 
seller server may delay until end of the day, or until a predetermined number of offers are 
received. After the predetermined time is reached, the offer having the greatest offer price is 

2 0 selected (step 1 104) and the selected offer is accepted (step 1 106). Then as described above, 
payment is received using the payment identifier (step 1 108) and an acceptance message is 
sent to the appropriate buyer that submitted the selected offer (step 1110). The method may 
then continue at step 1 102 with more offers being received. Any offers that were received 
but not accepted may be stored and possibly evaluated during the next cycle. For example, if 

2 5 in a first cycle one hundred offers are received, and only one offer is accepted, then in a 
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second cycle another hundred offers may be received. Thus, in the second cycle there are one 
hundred and ninety nine offers to evaluate, and the offer having the highest offer price may 
be accepted. 

It can be desirable to prevent the minimum acceptable price of a product from 
being disclosed. For example, competitors of a seller could take advantage of the minimum 
acceptable price by adjusting their prices accordingly. In addition, if buyers knew the 
minimum acceptable price of a product they would have no incentive to submit offer prices 
greater than the minimum acceptable price, even if they would otherwise be willing to do so. 

Referring to FIG. 12, a flow chart 1200 illustrates a method for concealing a 
minimum acceptable price of a product. The illustrated method may performed, for example, 
for each offer received. 

The seller server generates a random number between zero and one (step 
1202) in a manner known in the art. If the random number is not less than 0.01 (step 1204), 
then the seller server determines whether to accept the offer using the normal methods of the 
present invention described herein (step 1206). Thus, the normal methods are applied 
approximately ninety nine percent of the time (1 - 0.01 = 0.99 = 99%). Those skilled in the 
art will realize that the probability of performing the normal methods may be altered as 
desired, as may the method of randomly selecting when to perform the normal methods. 

If the random number is in the range from 0.00 to 0.01, then the seller server 
determines whether to accept the offer without considering the offer price (step 1208). In one 
embodiment, the determination of whether to accept the offer may be based solely on product 
availability. For example, if a product exists which may satisfy the offer, then the offer may 
be accepted regardless of the offer price. 

In the illustrated embodiment, since approximately one percent of all offers 
are accepted based solely on product availability or based on other criteria besides the offer 
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price, offers having extremely small offer prices may still be accepted. Accordingly, it would 
be difficult to ascertain the minimum acceptable price of the product. In addition, since such 
offers may be accepted relatively rarely, the loss to the seller of selling below its minimum 
acceptable price is likely to be insignificant. 

As described above, the present invention can allow a seller to accurately 
assess the demand for various products since submitted offers are "guaranteed" by some form 
of payment and thus are unlikely to be impulsive or capricious. Consequently, the seller may 
use the demand assessment to its advantage in such tasks as setting the prices of products and 
setting the future supplies of products. 

Referring to FIG. 13, a flow chart 1300 illustrates a method for assessing 
demand for a product. As described above, the seller server receives a plurality of offers that 
are appropriate for a product, as well as associated payment identifiers (step 1302). An offer 
is appropriate for the product if the product satisfies each condition of the offer. Offers that 
are appropriate for other products are evaluated in a similar manner for the other products. 

The seller server selects offers that were accepted or that are likely to be 
accepted (step 1304). Accepted offers may be advantageously used to assess true demand 
which is also acceptable to the seller (i.e. demand that does not include unreasonably small 
offer prices). Data from the plurality of offers, or just the accepted offers, are stored, such as 
in the collected demand database 250 (FIG. 2). The stored data may be used in generating 
graphs, such as the graph 700 (FIG. 7), to represent the associated demand. 

The (future or current) price, which may be the retail price and/or the 
minimum acceptable price, of the product is adjusted based on the offer prices of the accepted 
offers (step 1306). For example, if the offer prices indicate great demand and/or great 
willingness to pay large offer prices for the product, the price of the product may be 
increased. Similarly, the future supply of the product is adjusted based on the offer prices of 
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the accepted offers (step 1308). For example, if the offer prices indicate great demand and/or 

great willingness to pay large offer prices for the product, the seller may take steps to 

increase the supply of the product, such as increasing manufacturing or otherwise making 

more units of the product available for sale. 

In another embodiment, all demand, whether accepted or not, may be used in 
making the above-described adjustments. Similarly, the seller server may base its 
adjustments on data from the plurality of offers besides offer prices, such as when the offers 
were submitted and the number of offers submitted. Those skilled in the art will understand 
that the present invention contemplates many types of data from offers may be used to adjust 
prices and supplies of products. 

Although the present invention has been described with respect to a preferred 
embodiment thereof, those skilled in the art will note that various substitutions may be made 
to those embodiments described herein without departing from the spirit and scope of the 
present invention. For example, many methods described above as being performed by the 
seller server may be performed by the central server if desired. Furthermore, much of the 
invention and associated advantages disclosed herein can be equally applicable to an 
environment in which any given offer is submitted to more than one seller. 



22 



